Pull Request Test Coverage Report for Build 401

• 1 of 1 (100.0%) changed or added relevant line in 1 file are covered.
• 1 unchanged line in 1 file lost coverage.
• Overall coverage increased (+0.6%) to 74.079%

Totals
Change from base Build 394:	0.6%
Covered Lines:	583
Relevant Lines:	787

💛 - Coveralls

Wow. Thank you for this contribution.

This bit of code existed from the very early beginnings of the project, where one it's first uses were on mulesoft applications. The mule packaging type from the mulesoft plugins worked by attaching a .zip file, but didn't properly map that the 'mule' package should produce a .zip, causing issues. The resulting idea was to just use the extension from the attached artifact file rather than the extension defined by the packaging type (which wasn't defined) and log a warning that things weren't configured properly with the packaging plugin being used (in my previous case - mule).

I never modeled a test case for this, because I'd moved on from supporting the mulesoft app efforts at that client, and without a test case existing, forgot about this. :-( It may have been that the master branch builds would have failed for those projects as well -- I don't think those projects ever updated to using this plugin, and if they did, they'll be using a very old version of the plugin and this won't matter anyhow. :-)

So if I'm looking at this PR properly, this should get things 'working' again for you, and for other properly-configured packaging plugins.

Anyone want to take a stab at seeing if a mulesoft package will work with this?

It looks like the Artifact Type Registry doesn't always return the right extension. For example the Maven Bundle Plugin offers a packaging type bundle, with extension jar. See its components.xml. Using the ArtifactHandler instead of the Type Registry does return the correct extension, and also works for the other cases (e.g. files attached with the Build Helper Maven Plugin).